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(57) Abstract: A system and method for processing financial service applications include a flexible interface (208) to a variety of 
sources for application data, and uses an automated method for generating graphical user interfaces (208) in the preferred embod- 
iment The system processor (210) can operate in either batch or real time mode to accommodate a variety of data sources and to 
level system loading. The system also includes a second flexible interface (208) to a variety of decision engines (200, 202, 204, 206). 
The method supports use of a single decision engine (200, 202, 204, 206), but also accommodates the use of two or more decision 
engines in parallel or in series to process data from the same application. Interfaces (208) to the decision engines and customer input 
ports may be custom generated. An automated method for generating Graphical User Interfaces (GUIs) is illustrated in the context 
of a system for processing financial applications. In one embodiment, the GUI generator converts domain data representing over one 
thousand application types into an equal number of corresponding user screens. The interface may also be bi-directional, operating 
on user inputs to validate data or check for double keying. 

BEST AVAILABLE COPY 



SYSTEM AND METHOD FOR PROCESSING APPLICATIONS 
FOR FINANCIAL SERVICES 

FIELD OF THE INVENTION 

The invention relates generally to the processing of financial data, and more 
particularly to a system and method for processing applications for financial services 
such as consumer credit card accounts, home mortgage loans, or other services. One 
embodiment of the invention incorporates the automated generation of graphical user 
interfaces (GUI's). 

BACKGROUND OF THE INVENTION 

Present-day consumers have come to rely on the convenience of credit cards and 
other financial services. There is a high volume of new account applications for such 
services, even in the credit card industry, for example, where there is already a large base 
of existing credit card holders. Several factors may account for the high volume of credit 
card applications: consumers who have recently reached the age of majority are applying 
for their first credit card; existing credit card users often change from one credit service 
provider to another in order to obtain more favorable terms; and some credit card holders 
desire additional or upgraded credit cards. 

The financial services industry is competitive. Banks and other financial service 
providers therefore may review a large number of applications in a limited amount of 
time, and they must make good decisions regarding the credit-worthiness of potential 
borrowers. Automated systems have been developed to process applications quickly and 
to track individual credit applications through the review process. Many application 
processing systems manage risk by employing a decision engine to consistently apply 
best business practices associated with the selection of customers. 

Known systems and methods for processing high volumes of credit applications 
receive data from a single input channel, operate either in batch mode or in real-time 
mode, make credit decisions using a single decision engine, and customize user 
interfaces for different application types. Drawbacks of such implementations are 
considered below. 
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Credit applications typically include information such as name and address of the 
applicant(s), and may include information such as employment history, monthly income, 
monthly financial obligations, and the amount of credit being applied for. Potential 
customers submit credit applications to banks or other financial institutions through 

5 various channels. A drawback of existing application processing systems is that they are 
typically configured to accept applications from a single channel, for example paper 
applications received in the mail, applications submitted via the Internet, or applications 
received over the phone. Moreover, application processing systems may operate in a 
mode that is tailored to the type of input channel. For example, systems that process 

10 paper applications typically process in batch mode, whereas an interactive Internet 
application requires real time processing. It is inefficient for financial institutions to 
implement and maintain separate systems for processing applications that are submitted 
through different channels. On the other hand, it is a convenience to applicants, and thus 
a benefit to financial service providers, to offer a variety of application input alternatives. 

15 Credit decisions are often made on the basis of information from the credit 

application itself, and from historical credit information provided by one or more 
independent credit bureaus. Decision engines typically include software implementations 
of algorithms designed to quantify risk based on such information, resulting in a 
determination as to whether credit should be offered to a particular applicant, and, if so, 

20 under what terms. Such algorithms are constantly evolving. As a consequence, 
application processing systems tailored to a particular decision engine may quickly 
become obsolete. 

Additionally, many data processing systems, including those that process 
applications for financial services, are required to accommodate a variety of different 

25 user interface screens. A financial service provider may, for example, have hundreds of 
different new account application formats related to the variety of services it offers to 
consumers. System developers respond to this need by coding or scripting a variety of 
user interfaces that are tailored to the requirements of each application. Unfortunately, 
user interface requirements may be dynamic for many data processing operations. A 

30 financial services provider, for example, may wish to offer new services, may require 
new information to process existing products, or may simply change the layout of a user 



interface to make it more user-friendly. The result can be a high level of maintenance in 
the form of software support, which may be both costly and time-consuming. 

Thus, existing application processing systems may have narrow operational value, 
and may require frequent modification. These and other drawbacks limit the efficiency 
of such systems. 

SUMMARY OF THE INVENTION 

The invention overcoming these and other drawbacks in the art relates a system 
and method that may accept applications for financial services from a variety of input 
channels, may operate in various processing modes, may utilize one or more decision 
engines during operation, and may generate user interface script automatically. 

It is an object of the invention to make the process of applying for financial 
services more convenient for consumers. The techniques described herein for enabling a 
variety of input channels and for processing applications in a variety of modes may 
provide more data input options for applicants and may be a more efficient use of 
computing resources for financial institutions. 

It is another object of the invention to provide financial institutions with a more 
powerful technique for automating credit decisions. A flexible interface to decision 
engines may be advantageous for several reasons. First, this type of interface may make 
multiple types of decision engines available simultaneously. This would be a benefit, for 
example, where different engines are used together to make decisions on different 
financial products, or where two or more decision engines are used to make a single 
determination. Moreover, a flexible interface may significantly reduce the cost of 
replacing decision engines in the overall system, when and if it becomes necessary. 

It is another object of the invention to eliminate or reduce the amount of manual 
scripting required to support new user interfaces to data processing systems. By 
automatically generating user interface script based on functional parameters, it is no 
longer necessary to manually develop screen interfaces for the variety of applications that 
may be supported by any one system. This technique may be executed in situ (i.e., in the 
process of each user transaction), or it may be executed only once after a new application 
has been defined (in which case the resulting user interface script would be stored for 
later use). 



In one embodiment o: % the invention, an applicant may communicate with the data 
processing system via the Internet The applicant may further select a particular financial 
service from a menu of choices. In response, the script generator creates an appropriate 
user interface, which is presented to the user for completing and submitting an 
application for the selected financial service. The system processes the application data 
in a mode that is tailored to the input channel; here, it is likely that the system will 
operate in real time mode. The system may then select and employ one or more decision 
engines, as appropriate for the type of application that is to be processed. Once a 
determination has been made whether to perform financial services for the applicant, the 
data processing system notifies the applicant that their application has been either 
accepted or rejected. 

The following drawings and descriptions further describe the invention, including 
several different embodiments of the major system components and processes. The 
construction of such a system, implementation of such a process, and advantages will be 
clear to a person skilled in the art of data processing generally, including financial 
services. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is the schematic diagram of a system that processes applications for 
financial services, according to one embodiment of the invention. 

Figure 2 is a flow diagram illustrating the logical relationship between functional 
components of a system that processes applications for financial services, according to 
one embodiment of the invention. 

Figure 3 is a flow diagram illustrating a method for processing applications 
related to financial services, according to one embodiment of the invention. 

Figure 4 is a flow diagram illustrating the inputs and outputs of an automated 
Graphical User Interface (GUI) generator, which has been adapted for mediating 
communication between an application processing system and an applicant. 

Figure 5 is a flow diagram illustrating a method for mediating communication 
between a system and a user, according to one embodiment of the invention. 
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Figure 6 is the schematic of a user screen resulting from operation of an 
automated Graphical User Interface (GUI) generator, according to one embodiment of 
the invention. 

5 

DETAILED DESCRIPTION OF THE INVENTION 

Figure 1 illustrates a system architecture for processing applications related to 
financial services according to the invention. A purpose of the system is to connect 
sources of electronic application data to decision engines and credit bureaus, and to host 

10 programs that coordinate the processing of application data. The schematic depicts 
among other possible resources: servers 114, 116, 118, 120, 122, 126 and 130; clients 
104, 108, and 110; and databases 124, 128, 132 and 134. Servers and clients are 
connected via communication link 1 12, according to one embodiment of the invention. 

Server 114 may perform or coordinate the processing of financial applications 

15 including functions such as data collection, validation, tracking, reconciliation, repair, 
routing, fulfillment, and reporting functions. Servers 116, 118, and 120 represent a 
variety of decision engines that such a system may include or interface to. Servers 122, 
126 and 130 illustrate various credit bureau servers that the system may utilize to obtain 
credit history for a given applicant. Servers 1 14, 1 16, 1 1 8, 120, 122, 126 and 130 may be 

20 or include, for instance, a workstation running the Microsoft Windows™ NT™, 
Windows™ 2000, Unix, Linux, Xenix, IBM AIX. Hewlett-Packard UX. Novell 
Netware™, Sun Microsystems Solaris™, OS/2™, BeOS™, Mach, Apache, OpenStep™ 
or other operating system or platform. 

Clients 104. 108, and 110 represent various sources for applications related to 

25 financial services. All provide applications to the processing system in electronic format. 
Client 104 depicts a source of electronic applications where paper documents 100 have 
been converted into electronic format by a scanner 102. Client 108 depicts a source for 
electronic applications originating via telephonic input 106. Client 110 depicts a direct 
user interface. Clients 104, 108, and 110 may be or include, for instance, a personal 

30 computer running the Microsoft Windows™ 95, 98, Millenium™, NT™, or 2000, 
Windows™CE™, PalmOS™, Unix, Linux, Solaris ™, OS/2 ™, BeOS ™, MacOS ™ or 



other operating system or platform. Clients 104, 108, and 110 may include a 
microprocessor such as an Intel x86-based device, a Motorola 68K or PowerPC™ 
device, a MIPS, Hewlett-Packard Precision™, or Digital Equipment Corp. Alpha™ 
RISC processor, a microcontroller or other general or special purpose device operating 
under programmed control. Clients 104, 108, and 110 may furthermore include 
electronic memory such as RAM (random access memory) or EPROM (electronically 
programmable read only memory), storage such as a hard drive, CDROM or rewritable 
CDROM or other magnetic, optical or other media, and other associated components 
connected over an electronic bus, as will be appreciated by persons skilled in the art. 
Clients 104, 108, and 1 10 may also be or include a network-enabled appliance such as a 
WebTV™ unit, radio-enabled Palm™ Pilot or similar unit, a set-top box, a networkable 
game-playing console such as Sony Playstation™ or Sega Dreamcast™, a browser- 
equipped cellular telephone, or other TCP/IP client or other device. 

Databases 124, 128 and 132 may include credit history data for applicants and 
non-applicants, as maintained by various credit bureaus. Database 134 may include 
application data, application status information, and programs used by the application 
processing system 114. Databases 124, 128, 132 and 134 may be, include or interface to, 
for example, the Oracle™ relational database sold commercially by Oracle Corp. Other 
databases, such as Informix™, DB2 (Database 2) or other data storage or query formats 
or platforms such as OLAP (On Line Analytical Processing), SQL (Standard Query 
Language), Microsoft Access™ or others may also be used, incorporated or accessed in 
the invention. 

Communication link 112 connects servers 114, 116, 118, 120. 122, 126 and 130 
to each other and to clients 104, 108, and 110. Communications link 112 may be, 
include or interface to any one or more of, for instance, the Internet, an intranet, a PAN 
(Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network) 
or a MAN (Metropolitan Area Network), a frame relay connection, an Advanced 
Intelligent Network (AIN) connection, a synchronous optical network (SONET) 
connection, a digital Tl, T3, El or E3 line, Digital Data Service (DDS) connection, DSL 
(Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated 
Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog 



modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, 
or FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) 
connections. Communications link 112 may furthermore be, include or interface to any 
one or more of a WAP (Wireless Application Protocol) link, a GPRS (General Packet 
5 Radio Service) link, a GSM (Global System for Mobile Communication) link, a CDMA 
(Code Division Multiple Access) or TDMA (Time Division Multiple Access) link such 
as a cellular phone channel, a GPS (Global Positioning System) link, CDPD (cellular 
digital packet data), a RIM (Research in Motion, Limited) duplex paging type device, a 
Bluetooth radio link, or an IEEE 802.11 -based radio frequency link. Communications 
10 link 112 may yet further be, include or interface to any one or more of an RS-232 serial 
connection, an IEEE- 1394 (Firewire) connection, a Fibre Channel connection, an IrDA 
(infrared) port, a SCSI (Small Computer Serial Interface) connection, a USB (Universal 
Serial Bus) connection or other wired or wireless, digital or analog interface or 
connection. 

15 Servers 114, 116, 118, 120, 122, 126, 130 and clients 104, 108, and 110 may 

utilize networked enabled code related to communication link 112. Network enabled 
code may be, include or interface to, for example, Hyper text Markup Language 
(HTML), Dynamic HTML, Extensible Markup Language (XML), Extensible Stylesheet 
Language (XSL), Document Style Semantics and Specification Language (DSSSL), 

20 Cascading Style Sheets (CSS), Synchronized Multimedia Integration Language (SMIL), 
Java™, Jini™, C, C-H-, Perl, UNIX Shell, Visual Basic or Visual Basic Script, Virtual 
Reality Markup Language (VRML) or other compilers, assemblers, interpreters or other 
computer languages or platforms. 

Figure 2 is a flow diagram illustrating the logical relationship between functional 

25 components of a system that processes applications for financial services according to 
one embodiment of the invention. One purpose of the processes depicted in Figure 2 is 
to make a decision, for each application, whether an offer should be made to an applicant 
for financial services such as a credit card account or a mortgage. The processes may 
also be used to establish terms of such an offer, for instance the maximum amount of 

30 money to be loaned, or the minimum interest rate to be charged. 

Many of the functional elements in Figure 2 can be related to components of the 
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system architecture depicted in Figure 1. For example, scanned applications 200 may 
reside on client 104; telephonic applications 202 may reside on client 108; and online 
applications 204 may be provided by client 1 10. Additionally, the functional elements in 
Figure 2 identified as the input interface 208, processor 210, and decision router 214 may 
5 be executed on server 114. Memory 212 may correspond to database 130. Decision 
engines 216, 218, and 220 may be embodied in servers 116, 118, and 120. Credit 
bureaus 224, 226, and 228 may operate through servers 122, 126 and 130. Data source 
206, decision engine 222, and credit bureau 230 are shown to indicate the expandability 
of the application processing method. The interface to fulfillment process 232 illustrates 

10 that a positive result from processing an application may be, for example, a downstream 
process that issues a credit card or provides some other consideration to the applicant. In 
another embodiment, fulfillment process 232 may interface more directly to decision 
engine 216, 218, 220, or 222. 

Advantageously, input interface 208 is adapted to receive electronic application 

15 data from a variety of input sources and types, depicted in Figure 2 as 200, 202, 204, and 
206. 

Processor 210 may perform or coordinate functions such as data collection, 
validation, tracking, repair, routing, fulfillment, and reporting. Data collection relates to 
application data received through interface 208. Validation may involve checking the 

20 application data received against a pre-defined set of criteria in order to identify data 
input or translation errors originating, for example, at sources 200, 202, 204, or 206. The 
repair function may be able to fix at least some of the errors types that are detected by the 
validation function. The routing function relates, for instance, to coordination of the 
decision router 214 described in more detail below. Processor 210 also may interfaces to 

25 or coordinate the passing of data to fulfillment process 232, for example in the case 
where a credit account is to be established or where a credit card is to be physically 
mailed to the customer of a bank or other financial institution. 

Processor 210 may operate on the application data in either batch or real time 
mode. Batch mode may operate on a group of applications only at off-peak hours. 

30 Alternatively, batch mode may operate both during peak and off-peak hours to achieve 
workload leveling (in effect reducing or eliminating peak loads). Real time mode is 
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required for interactive processing sessions, for example where an applicant is making 
application online and where a response is made to that applicant regarding an offer of 
financial services within seconds or minutes. Together, the flexible input interface 208 
and selectable modes of processor 210 maximize the efficiency of server 114 and 

5 decision engines 216, 218, 220, and 222, and eliminate the need for dedicated application 
processing systems for different application data sources or types. 

Decision router 214 performs at least three functions. First, it controls the routing 
of application data to decision engine(s) 216, 218, 220, and/or 222. Decision router 214 
may select a single decision engine, for example where decision engines 216, 218, 220, 

10 and 222 are each tailored for different financial services and where the applicant has only 
applied for a single financial service. Decision router 214 may select two or more 
decision engines to process the application data simultaneously, for instance where the 
applicant has applied for more than one type of financial service. Such parallel 
processing may also be appropriate where the results of two or more decision engines are 

15 used to make a determination as to an offer for a single financial service. Decision router 
214 may also select two or more decision engines to process the application data in serial 
fashion. This may be advantageous, for example, where the single financial service 
applied for was denied, but where the financial institution wishes to consider other 
financial services that it might offer to the applicant. Additionally, two or more decision 

20 engines may be selected for serial operation where the results of one decision engine can 
be used in subsequent calculations by another decision engine. Better decisions 
regarding offers for financial services may result from the ability to select and employ 
one or more decision engines during application processing. 

A second function of decision router 214 is to provide formatting of the 

25 application data as. required by each type of decision engine. In general, different 
developers may have coded decision engines 216, 218, 220, and 222, and they may have 
done so at different times. It is therefore unlikely that the required formats for the 
application data that they process are consistent. Decision router 214 may therefore 
utilize a library of decision engine proxies to format application data received from input 

30 sources 200, 202, 204, or 206 into the appropriate format for decision engines 216, 218, 
220, and/or 222. The flexibility of this interface allows those who maintain the 
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application processing system to readily connect to new or different decision engines. 
This may result in substantial time and cost savings. 

A third function performed by decision router 214 is to receive the decisions 
reached by decision engines 216, 218, 220, and/or 222 and route them to other decision 

5 engines or to processor 210, as appropriate. 

Figure 2 also illustrates that decision engines 216, 218, 220, and 222 may each 
obtain historical credit information from one or more credit bureaus 224, 226, 228 and 
230 that is considered together with application data from input sources 200, 202, 204, 
and 206 in making credit or other decisions. The decision engines, 216, 218, 220 and 

10 222 may include, for example, the commercial Magnum™, ACAPS™, FirstClass™ or 
other engine or service. 

Figure 3 is a flow diagram illustrating a method for processing applications 
related to financial services according to one embodiment of the invention. The diagram 
demonstrates that after an appropriate start 300, typically the receipt of application data, 

15 the processor must determine the input channel 302 from which the data came. If the 
data originated with a scanned paper application 304 or other non-interactive session 
324, then batch mode is selected 310. Batch mode may function by placing data in a 
queue 312 until the queue becomes full 314 or until the processor determines that the 
decision engines have sufficient processing capacity (as with the load leveling technique 

20 described above). Thereafter, one or more decision engines are selected 316, and all 
applications in the batch are sent 318 to the decision engine(s). After decisions are 
received 320, positive results are sent to the fulfillment process 322. 

Figure 3 also illustrates that data from telephonic applications 306 or Internet 
applications 308 that are part of an interactive session 324 are selected 326 for real time 

25 processing. In real time mode, one or more decision engines must also be selected 328 
before applicant data is sent 330 to the decision engines. In contrast to the batch mode, 
however, once results are returned 332, notification is made to the applicant in real time 
334 before initiating the interface to the fulfillment process 322. 

The dual mode capability illustrated by Figure 3 provides an advantage for 

30 financial entities: separate systems for batch and real time processing of financial 
applications are not required. This may result in lower operating and support costs. 
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In an another embodiment of the process shown in Figure 3, both alternatives 
operate in real time mode. In this instance, the only difference between alternative flows 
may be that one processing path provides for real-time feedback (process-and-notify) 
whereas the other does not (process). 

5 Figure 4 is a flow diagram illustrating the inputs and outputs of an automated 

Graphical User Interface (GUI) generator 500, which has been adapted for mediating 
communication between an application processing system and an applicant. The initial 
input is represented by domain data 400. Domain data 400 may include, for example, the 
name of an applicant and the location on the application that the name is to be found. 

10 Domain data 400 may similarly include the description and location of the applicant's 
address, present employer, or other information. Domain data 400 may be generated 
manually, for example by key entry, or it may be automated, as in the case of document 
scanning and character recognition. Generation of domain data 400 may further involve 
automatic conversion from a flat file format to XML format. The output of GUI 

15 generator 500 may be a User screen 600 that has been tailored for collecting and 
displaying information relevant to one or more financial services. There may be 
hundreds or even thousands of different embodiments of user screen 600. Automated 
generation of the user interface eliminates the time and expense that would otherwise be 
associated with manual code generation. 

20 User screen 600 may further have a spatial correspondence to the variety of paper 

applications that it relates to. This may be an advantage, for example, where an agent of 
the financial entity processing the application is comparing the electronic version of 
application data to an original paper copy of the application. Where a user adds data to 
user screen 600, data from that screen may then become another input to GUI Generator. 

25 Figure 5 is a flow diagram illustrating a method for mediating communication 

between a system and a user, according to one embodiment of the invention. All 
processes shown may be implemented via application software included in input 
interface 208, and may reside on server 114. In the instance where GUI generator 500 is 
to display a user screen 600 based on domain data 400, the GUI mediator 502 calls 

30 HTML factory 508 and utilizes XSL transformation 510 to convert XML formatted 
domain data 400 into an HTML user screen 600. In the instance where GUI generator 
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500 is to receive data that is i lput on user screen 600, GUI mediator 502 may validate the 
input data using GUI validatcr 504 and/or GUI double key checking 506. 

GUI validator 504 may use a rules engine to perform a validation on the data 
entered by the user in step 600. Such rules may be encoded in a database using Java-like 
syntax, and may be loaded on instantiation of the service. GUI validator 504 may be 
implemented according to the JavaCC rules engine. 

The GUI double key checking process 506 may be responsible for scanning the 
XML document to determine, for example, which fields need to be double keyed. In one 
embodiment, all double keyed fields may be cleared of text and returned to the user for 
re-keying. The original values may be stored in the document. If the re-key and the 
original input match, the document may be forwarded. 

Figure 6 is the schematic of a user screen resulting from operation of an 
automated Graphical User Interface (GUI) generator, according to one embodiment of 
the invention. The notional schematic illustrates that a user screen 600 may include a 
tool bar 602, drop down menu, or similar technique for selecting user functions. User 
screen 600 may also include data fields for collecting or correcting applicant data 604, or 
for defining, selecting, or viewing information about financial services that may be 
offered to the applicant 606. 

The specification and examples provided above should be considered exemplary 
only. It is contemplated that the appended claims will cover any other such embodiments 
or modifications as fall within the true scope of the invention. 
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What is claimed is : 

1 . A system for processing applications for financial services, comprising: 
an interface to at least one source of application data; 

a processor; 

a decision router; and 

an interface to at least two decision engines. 

2. The system of claim 1, wherein the application data comprises information for at 
least one credit account application, mortgage account application, bank account 
application, or other financial service. 

3. The system of claim 1, wherein the sources of application data comprise data from 
paper applications that have been converted to electronic format. 

4. The system of claim 1, wherein the sources of application data comprise telephonic 
applications that are the result of an automated process. 

5. The system of claim 1, wherein the sources of application data comprise telephonic 
applications that are the result of an interaction with an operator. 

6. The system of claim 1, wherein the sources of application data comprise online 
sessions with applicants. 

7. The system of claim 1, wherein the sources of application data comprise online 
sessions with agents of an entity offering financial services. 

8. The system of claim 1, wherein the processor is at least temporarily configured to 
operate in batch mode. 

9. The system of claim 1, wherein the processor is at least temporarily configured to 
operate in real time mode. 

10. The system of claim 1, wherein the decision engines are adapted to make decisions 
on the same type of financial service. 

11. The system of claim 1, wherein the decision engines are adapted to make decisions 
on different types of financial services. 

12. The system of claim 1, wherein the system comprises at least one interface for 
providing a result to an applicant. 

13. A method for making decisions regarding applications for financial services, 
comprising: 
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(a) receiving application data from at least one source; 

(b) processing the application data; and 

(c) routing the data to at least one decision engine; 

(d) wherein the step (c) of routing considers at least two alternative decision engines. 
5 14. The method of claim 9 wherein the step (a) receiving comprises the application of an 

automated Graphical User Interface (GUI) Generator to display a user screen. 

15. The method of claim 9 wherein the step (a) receiving comprises the application of an 
automated Graphical User Interface (GUI) Generator to receive data from a user. 

16. The method of claim 9 wherein the step (b) processing comprises a batch operation. 
10 17. The method of claim 9 wherein the step (b) processing comprises a real time 

operation. 

18. The method of claim 9 wherein the step (b) processing comprises a load leveling 
scheme. 

19. The method of claim 9 wherein the step (c) routing comprises the selection of a 
15 single decision engine. 

20. The method of claim 9 wherein the step (c) routing comprises the selection of at least 
two decision engines to be used in parallel. 

21. The method of claim 9 wherein the step (c) routing comprises the selection of at least 
two decision engines to be used in series. 

20 22. A method for generating a graphical user interface, comprising: 

(a) receiving domain data; 

(b) converting the domain data to a presentable format; and 

(c) displaying a user screen according to the domain data received in step (a) and the 
resulting format from the conversion in step (b); 

25 (d) wherein each user screen substantially reflects the layout of a printed application 

for financial services. 

23. The method of claim 22, wherein the step (a) of receiving comprises inputting data 
manually. 

24. The method of claim 22, wherein the step (a) of receiving comprises collecting data 
30 from a scanner in a semi-automated process. 
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25. The method of claim 22, wherein the step (a) of receiving comprises interfacing to a 
pre-existing database of domain data 

26. The method of claim 22, wherein the step (a) of receiving comprises automated 
conversion from a flat file to data in Extensible Markup Language (XML) format. 

5 27. The method of claim 22, wherein the step (b) of converting comprises a step (e) of 

translating from Extensible Markup Language (XML) to Hyper Text Markup 

Language (HTML) format. 
28. The method of claim 27, wherein the step (e) of translating is accomplished with 

application of Extensible Stylesheet Language (XSL). 
10 29. The method of claim 22, wherein the step (b) of converting is accomplished with 

application of Extensible Stylesheet Language (XSL) without resulting in Hyper Text 

Markup Language (HTML) format. 
30. The method of claim 22, wherein the step (b) of converting comprises application of 

Document Style Semantics and Specification Language (DSSSL). 
15 31. The method of claim 22, wherein the step (b) of converting comprises application of 

Cascading Style Sheets (CSS). 

32. The method of claim 22, wherein the step (b) of converting is executed on an as- 
needed basis in response to user action. 

33. The method of claim 22, wherein the step (b) of converting is executed when 
20 triggered by a change in domain data. 

34. The method of claim 22, wherein the step (b) of converting is executed at scheduled 
intervals. 
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